Activity: Model the User Interface

Describe the Characteristics of Related Actors

Describe the characteristics of the (human) actors related to the use case. Focus on describing the primary actor of the use case since the major part of the interaction involves this actor. This information is important for the subsequent steps below.

Refer to section "Actor Characteristics" in Guidelines: Actor for details.

Create a Use-Case Storyboard

Start by creating a use-case storyboard for the use case, and assign a trace dependency between the two. The use-case storyboard has various properties, such as text fields and diagrams, that describe the usability aspects of the use case.

A use-case storyboard in the analysis model can be traced to a use case in the use-case model.

Refer to Guidelines: Use-Case Storyboard for details.

Describe the Flow of Events - Storyboard

The step-by-step description of each use case that is input to this activity need to be refined and focused on usability issues; this refinement is captured in the Flow of Events - Storyboard property of the use-case storyboard.

Start by creating an initial outline of the Flow of Events - Storyboard using brief action statements, to acquire an understanding of the use case.

Then complement the Flow of Events - Storyboard with desired guidance, average values and volumes of objects, and average action usages for the different parts of the flow of events.

Refer to section "Describing the flow of Events - Storyboard" in Guidelines: Use-Case Storyboard for details.

Capture Usability Requirements on the Use-Case Storyboard

Capture the usability requirements on the use-case storyboard, defining how high the usability of the user interface must be.

Refer to section "Capturing Usability Requirements on the Use-Case Storyboard" in Guidelines: Use-Case Storyboard for details.

Find Boundary Classes Needed by the Use-Case Storyboard

In this step we identify the central and primitive boundary classes needed to provide the user interface of the use case.

Identify Central Boundary Classes

Identify one central boundary class representing the primary window with which the actor is interacting. If such a class already exists, consider reusing it. This is because you should strive to minimize the number of primary windows a particular actor needs to interact with. However, you will, of course, have to compromise; primary windows should not be too complex or cluttered.

These central boundary classes are often aggregates of more primitive boundary classes (see below).

Examples of Central Boundary Classes:

The central boundary class identified in a mail application is Mail Box. For details, refer to Guidelines: Boundary Class.

The central boundary class identified in a document editor is Document. For details, refer to Guidelines: Boundary Class.

Identify Primitive Boundary Classes

Study the flow of events - storyboard in detail, and any other use-case descriptions at hand. Look for information interesting to the user, and information that needs to be visible and managed in the user interface.

Consider any business entity objects, or terms (especially nouns) in a glossary. Also consider entity objects if they exist. These are ways of gaining an understanding of what information is manipulated by the system and is thereby also interesting to the user.

Then, create one boundary class for each logical object manipulated by the actor via the user interface. When doing this, always consider reusing already existing boundary classes. The result of this step will prepare for the building of an object-oriented user interface.

Examples of Primitive Boundary Classes:

The primitive boundary classes identified in a mail application include Mail Message Attachment. For details, refer to Guidelines: Boundary Class.

The primitive boundary classes identified in a document editor include Paragraph and Footnote. For details, refer to Guidelines: Boundary Class.

Outline the Identified Boundary Classes

Describe obvious things about the boundary classes. At this stage, it is often possible to outline most of their attributes, aggregations, associations, and also some of their responsibilities. Recall that central boundary classes are often aggregations of more primitive boundary classes.

Each class will be refined and described in detail in the steps below; please refer to the steps below for examples.

Relate the Boundary Classes to the Use-Case Storyboard

The boundary classes participating in a use-case storyboard need to be related to it. This is done by capturing the classes in class diagrams, including their relationships, attached to the use-case storyboards.

For details, refer to section "Creating Boundary Class Diagrams" in Guidelines: Use-Case Storyboard.

Describe Interactions Between Boundary Objects and Actors

This step is optional and is done if the interaction sequence (e.g., flow of windows and navigation paths) needs to be captured formally in an interaction diagram.

Step through the flow of events of the use case (or more precisely, the subset of the use case under consideration in the current iteration), identifying the boundary objects responsible for the visible behavior of the use case. Note that these boundary objects are instances of the boundary classes as found in the previous step (Find Boundary Classes Needed by the Use-Case Storyboard). Illustrate the interactions between the participating boundary objects by creating one or more collaboration diagrams.

The collaboration diagram should also show interactions between the system and its actors. The flow of events usually begins when one of the actors requests something from the system, since an actor always invokes the use case.

Illustrate the interactions between objects by creating links between them; annotate the links with a short description of the intent of the invoking object, i.e. what it wants to achieve in the interaction with the invoked object. These "intents" will then be integrated into responsibilities on each corresponding boundary class, as described in the following step (Describe Responsibilities of Boundary Classes).

For details, refer to section "Creating Boundary Object Interaction Diagrams" in Guidelines: Use-Case Storyboard.

Complement the Diagrams of the Use-Case Storyboard

This step is optional and is done if the diagrams and descriptions (as created above) need to be complemented and further clarified with references to an already existing user-interface prototype (if any).

For details, refer to section "Complementing the Diagrams of a Use-Case Storyboard" in Guidelines: Use-Case Storyboard.

Refer to the User-Interface Prototype from the Use-Case Storyboard

This step is optional and is done if the diagrams and descriptions (as created above) need to be complemented and further clarified with references to an already existing user-interface prototype (if any).

For details, refer to section "Referring to the User-Interface Prototype from the Use-Case Storyboard" in Guidelines: Use-Case Storyboard.

Describe Responsibilities of Boundary Classes

The approach to follow in this step is similar to the one presented in the section "Describe Responsibilities" as described in the Activity: Use-Case Analysis. The only difference is that the demands are extracted from use-case storyboards instead of use-case realizations.

Note that a responsibility is a textual description of a cohesive subset of the behavior provided by a class. Given this, the responsibilities of boundary classes can be considered as high-level descriptions of the operations provided by the user interface and its windows.

For examples, refer to section "Examples of Boundary Class Responsibilities" in Guideline: Boundary Class.

Describe Attributes of Boundary Classes

The approach to follow in this step is similar to the one presented in the section "Describe Attributes and Associations" as described in the Activity: Use-Case Analysis.

Note that the attributes and their types should be conceptual, and serve as high-level descriptions of the properties of objects (such as windows) in the user interface. Also, these attributes may become classes themselves when the user interfaces is designed and implemented.

For examples, refer to section "Examples of Boundary Class Attributes" in Guidelines: Boundary Class.

Describe Relationships between Boundary Classes

In this step, we define aggregations, associations, and generalizations between boundary classes.

Aggregations and Associations

The approach to follow in this step is similar to the one presented in the section "Describe Attributes and Associations" as described in the Activity: Use-Case Analysis.

Generalizations

For examples, refer to section "Examples of Boundary Class Relationships" in Guidelines: Boundary Class.

Describe Usability Requirements on Boundary Classes

Most of the usability requirements on the use-case storyboard should be distributed onto the participating boundary classes, and be refined on the classes, if necessary.

For examples, refer to section "Examples of Special Requirements on Boundary Classes" in Guidelines: Boundary Class.

Present the Boundary Classes in Global Class Diagrams

Note that the class diagrams as created in the step Find Boundary Classes Needed by the Use-Case Storyboard above are local to the use-case storyboard. However, in some cases it is of value to present the boundary classes in "global" class diagrams that are not local to any use-case storyboard; for example, when used as input to the user-interface prototyping activity. For example, such class diagrams can include the following:

• The most important boundary classes and their relationships. Diagrams of this type can function as a summary of the model, and can be of great help in, for example, a review of the model, or in a prioritization of which parts of the model will be focused upon in the current iteration.
• Boundary classes that together constitute a specific user interface.
• Important, or deep, aggregation hierarchies of boundary classes.
• Associations between boundary classes in different aggregation hierarchies.
• Generalization hierarchies of boundary classes.

Evaluate Your Results

The use-case storyboards should be evaluated to verify that the work is headed in the right direction.

For check points on boundary classes, refer to section "Goodness Criteria on Boundary Classes and their Relationships" in Guidelines: Boundary Class.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Rational Unified Process